This addresses #20.

I would suggest adding this as a new message for protocol metadata so that it can be extended to other protocols, existing and future ones.

Example:

message ProtocolMetadata {
  optional HttpProtocol http_protocol ...
  optional TLSVersion tls_version ...
  optional QUICVersion quic_version ...
  ...
}

message Message {
  ...
  optional ProtocolMetadata protocol_metadata = 16;
  ...
}

I would suggest adding this as a new message for protocol metadata so that it can be extended to other protocols, existing and future ones.

Example:

message ProtocolMetadata {
  optional HttpProtocol http_protocol ...
  optional TLSVersion tls_version ...
  optional QUICVersion quic_version ...
  ...
}

message Message {
  ...
  optional ProtocolMetadata protocol_metadata = 16;
  ...
}

Why? This is no more extensible than adding those fields directly to Message but adds the additional overhead of encapsulating the fields inside a submessage. E.g. for protobuf-c users this requires another alloc.

Why? This is no more extensible than adding those fields directly to Message but adds the additional overhead of encapsulating the fields inside a submessage. E.g. for protobuf-c users this requires another alloc.

It's easier to find, read, understand, document and consumers that doesn't care for protocol metadata could skip it altogether.

But sure, they can be put in Message also as, at least IMO, if you're adding metadata about one protocol you should look at adding it for all the other that the specification support. There might also be a lot more interesting information to gather then just the HTTP protocol version.

Why? This is no more extensible than adding those fields directly to Message but adds the additional overhead of encapsulating the fields inside a submessage. E.g. for protobuf-c users this requires another alloc.

It's easier to find, read, understand, document and consumers that doesn't care for protocol metadata could skip it altogether.

All of the fields in the Message message, with the exception of the actual DNS wire messages themselves (query_message, response_message) are "metadata", and some of those metadata fields (e.g. socket_family, socket_protocol, the address/port fields) are specifically "protocol" or "connection" metadata, so I would find it somewhat confusing to put some of the protocol/connection metadata in Message and some of it in a submessage. (What would be the criteria for putting some metadata in Message and some metadata in a SomethingMetadata submessage?) So I don't agree with your assertion here. The fields in the Policy message went into an optional submessage, so it does seem plausible that some things should be placed in a submessage, maybe if they are tightly related and always appear together, or something.

consumers that doesn't care for protocol metadata could skip it altogether.

Sure, but they still pay the cost of the extra framing (handful of extra bytes per payload, plus allocs, when present).

But sure, they can be put in Message also as, at least IMO, if you're adding metadata about one protocol you should look at adding it for all the other that the specification support. There might also be a lot more interesting information to gather then just the HTTP protocol version.

I agree, it would also be nice to capture TLS and QUIC versions if those protocols are in use.